Skip to content

Conversation

@Picazsoo
Copy link
Contributor

@Picazsoo Picazsoo commented Feb 9, 2026

This change updates the generator to correctly map OpenAPI format: byte fields across all locations.

  • Query, Path, Header, Cookie, and Form fields: format: byte is generated as String (manual Base64 decoding required).
  • Multipart text fields: String.
  • Multipart file fields (format: binary): MultipartFile.
  • JSON request body DTO fields: byte[], with automatic Base64 decoding via Jackson.
  • Raw binary request bodies (application/octet-stream): Resource for streaming, no decoding applied.

This ensures all format: byte values are correctly typed across parameters and bodies, preserving the distinction between Base64-encoded values and raw binary.

The changes are practically limited to QueryParam; PathParam; HeaderParam; CookieParam; FormParam. But all the other types are asserted as well to prevent accidental regression.

fixes #22898

Tests performed:

Verified generated Java files for query, path, header, cookie, form, multipart, JSON body, and binary body fields.

Asserts confirm parameters and properties have the expected types (String, byte[], MultipartFile, Resource).

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package || exit
    ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
    ./bin/utils/export_docs_generators.sh || exit
    
    (For Windows users, please run the script in WSL)
    Commit all changed files.
    This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
    These must match the expectations made by your contribution.
    You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
    IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
  • File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
  • If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. - tagging: @cachescrubber (2022/02) @welshm (2022/02) @MelleD (2022/02) @atextor (2022/02) @manedev79 (2022/02) @javisst (2022/02) @borsch (2022/02) @Zomzog (2022/09) @martin-mfg (2023/08)

Summary by cubic

Converted byte[] operation parameters to String in the Java Spring generator for query, path, header, cookie, and form params. Spring doesn’t auto-decode base64 here, so we accept the raw base64 string to avoid type issues.

  • Bug Fixes

    • Map byte[] params in query/path/header/cookie/form to String via SpringCodegen (convertByteArrayParamsToStringType); templates add “base64 encoded binary” comments.
    • Preserve ByteArray → byte[] for models and JSON bodies; raw binary bodies remain Resource; multipart binary fields use MultipartFile. Explicit ByteArray → byte[] mapping added in AbstractJavaCodegen.
    • Added tests and new OAS fixtures; added a Spring Boot sample (springboot-byte-format-edge-cases) and wired it into CI; regenerated affected samples.
  • Migration

    • If you previously used byte[] for these params, decode the provided base64 String yourself (e.g., Base64.getDecoder().decode(value)).

Written for commit e0d2d56. Summary will update on new commits.

@Picazsoo Picazsoo marked this pull request as ready for review February 9, 2026 22:51
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 issues found across 41 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="samples/server/petstore/springboot-reactive-noResponseEntity/src/main/java/org/openapitools/api/FakeApi.java">

<violation number="1" location="samples/server/petstore/springboot-reactive-noResponseEntity/src/main/java/org/openapitools/api/FakeApi.java:383">
P2: @RequestPart is for multipart/form-data, but this endpoint consumes application/x-www-form-urlencoded. The modified parameter still uses @RequestPart, so WebFlux won’t bind the form body correctly (likely 400).</violation>
</file>

<file name="modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java">

<violation number="1" location="modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java:944">
P2: Form/multipart DTO still asserts `format: byte` as `byte[]`, but Spring’s default data binding does not Base64‑decode form strings to `byte[]`; it converts the string to raw bytes. This makes form DTO binding inconsistent with the new `String` parameter handling and can yield incorrect values without a custom converter.</violation>
</file>

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.

Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 issues found across 33 files (changes from recent commits).

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="samples/server/petstore/springboot-byte-format-edge-cases/src/main/java/org/openapitools/RFC3339DateFormat.java">

<violation number="1" location="samples/server/petstore/springboot-byte-format-edge-cases/src/main/java/org/openapitools/RFC3339DateFormat.java:16">
P2: RFC3339DateFormat hardcodes the delegate StdDateFormat to UTC and does not override setTimeZone, so any configured timezone will be ignored and dates will always format in UTC.</violation>

<violation number="2" location="samples/server/petstore/springboot-byte-format-edge-cases/src/main/java/org/openapitools/RFC3339DateFormat.java:36">
P2: clone() returns the same instance instead of a copy, violating the Format/DateFormat clone contract and preventing callers from obtaining an independent DateFormat instance.</violation>
</file>

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.

private static final long serialVersionUID = 1L;
private static final TimeZone TIMEZONE_Z = TimeZone.getTimeZone("UTC");

private final StdDateFormat fmt = new StdDateFormat()
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: RFC3339DateFormat hardcodes the delegate StdDateFormat to UTC and does not override setTimeZone, so any configured timezone will be ignored and dates will always format in UTC.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At samples/server/petstore/springboot-byte-format-edge-cases/src/main/java/org/openapitools/RFC3339DateFormat.java, line 16:

<comment>RFC3339DateFormat hardcodes the delegate StdDateFormat to UTC and does not override setTimeZone, so any configured timezone will be ignored and dates will always format in UTC.</comment>

<file context>
@@ -0,0 +1,38 @@
+  private static final long serialVersionUID = 1L;
+  private static final TimeZone TIMEZONE_Z = TimeZone.getTimeZone("UTC");
+
+  private final StdDateFormat fmt = new StdDateFormat()
+          .withTimeZone(TIMEZONE_Z)
+          .withColonInTimeZone(true);
</file context>
Fix with Cubic


@Override
public Object clone() {
return this;
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: clone() returns the same instance instead of a copy, violating the Format/DateFormat clone contract and preventing callers from obtaining an independent DateFormat instance.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At samples/server/petstore/springboot-byte-format-edge-cases/src/main/java/org/openapitools/RFC3339DateFormat.java, line 36:

<comment>clone() returns the same instance instead of a copy, violating the Format/DateFormat clone contract and preventing callers from obtaining an independent DateFormat instance.</comment>

<file context>
@@ -0,0 +1,38 @@
+
+  @Override
+  public Object clone() {
+    return this;
+  }
+}
</file context>
Fix with Cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG][SPRING] Incorrect handling of format: byte in query strings

1 participant